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Executive  Summary 


Problem  Definition  The  Aviation  and  Missile  Research,  Development,  and  Engineering  Center  (AM- 
RDEC)  Advanced  Science  and  Technology  Unmanned  Systems  Office  plans  the  way  ahead  for  UAS.  Their 
intent  is  to  pursue  technologies  that  increase  the  functionality  of  UAS  while  simultaneously  reducing  the 
workload  on  the  user.  Recent  Operations  Research  Center  of  Excellence  (ORCEN)  research  by  MAJ  Ed 
Teague,  DSE-R-0808,  showed  that  simple  rule  sets  can  organize  multiple  UAS  to  complete  tasks  with  little 
or  no  input  from  controllers/users  (Teague  and  Kewley,  2008).  As  a  matter  of  design,  DSE-R-0808  employed 
biomimicry  to  model  a  swarm  of  UAS  as  a  colony  of  ants,  where  each  UAS  dynamically  updates  a  global 
memory  map,  allowing  pheromone-like  communication  (see  DTIC:  ADA489366  for  additional  details).  In 
particular,  the  major  findings  of  DSE-R-0808  were: 

•  Semi- Autonomous  Self-Organizing  (SASC)  UAS  are  possible  using  preprogrammed  tasks  and  pheromone 
communication  methods. 

•  Depending  on  the  rate  of  pheromone  decay  and  the  influence  of  distant  pheromone  levels,  multiple  UAS 
seem  to  sufficiently  cover  a  large  area  without  any  input  beyond  a  global  rule  set. 

•  SASC  behaviors  were  tested  via  federated  simulation,  and  its  performance  is  comparable  to  prepro¬ 
grammed  routing  without  the  overhead. 


Technical  Approach  With  this  in  mind,  this  year’s  objective  was  to  advance  the  efforts  of  DSE-R-0808 
through  improved  rule  sets  in  order  to  achieve  better  results  using  doctrinal  mission  sets  employing  semi- 
autonomous,  self-organizing  UAS  in  dynamic  environments.  Accordingly,  the  principal  research  tasks  were 
as  follows: 

•  Develop  improved  rule  sets  for  controlling  swarming  behavior. 

•  Develop  a  modeling  and  simulation  test  bed  for  swarming,  small  UASs  in  order  to  test  the  differential 
aspects  of  system  components. 

•  Evaluate  various  UAS  parameters  to  see  how  efficient /effective  a  swarm  would  be  given  a  set  of  hardware 
(software)  and  recommend  hardware  (software)  solutions. 


Results  In  short,  we  successfully  implemented  and  tested  9  different  swarm  controllers,  using  a  stand¬ 
alone,  custom  Haskell  simulation  script  we  created.  Moreover,  in  addition  to  several  obvious  performance 
metrics,  we  developed  a  novel  measure,  volume  suppressed,  which  gauges  the  swarm’s  ability  to  minimize 
the  enemy's  windows  of  opportunity  (space/time  windows  for  the  enemy  to  maneuver  unobserved). 


Disclaimer 

Administratively,  this  study  was  funded  by  the  US  Army  Aviation  and  Missile  Research,  Development,  and 
Engineering  Center  as  part  of  a  year-long  effort  in  support  of  the  Statement  of  Work  entitled,  “Swarming 
UAS  II.”  The  U.S.  Government  is  authorized  to  reproduce  and  distribute  reprints  for  governmental  purposes 
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notwithstanding  any  copyright  annotation  thereon.  The  views  and  conclusions  contained  herein  are  those 
of  the  authors  and  should  not  be  interpreted  as  representing  the  official  policies  or  endorsements,  either 
expressed  or  implied,  of  the  AMRDEC,  USMA,  or  the  U.S.  Government. 
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2  BACKGROUND 


“Restless  thoughts,  like  a  deadly  swarm  of  hornets  arm’d,  no  sooner 
found  alone,  but  rush  upon  me  thronging.  ”  -  John  Milton 


1  Introduction 

It  was  perfect.  Sitting  on  the  edge  of  the  United 
States  Military  Academy’s  placid  Lusk  Reservoir,  I 
enjoyed  the  warmth  of  a  late  spring  sun,  a  pleasant 
easterly  breeze,  and  the  company  of  my  children,  as 
we  passed  the  afternoon  wetting  a  line.  Like  all  pre¬ 
vious  fishing  trips,  the  patience  of  my  youngest  was 
proportional  to  the  frequency  of  the  bite,  and,  al¬ 
though  the  weather  was  excellent,  the  fish  were  less 
than  cooperative.  Accordingly,  he  reeled  in  his  line 
and  decided  to  climb  a  small  tree  directly  behind 
us.  That’s  when  I  heard  it  -  the  guttural,  animal¬ 
istic  scream  that  every  parent  dreads.  My  son  was 
hurt. 

As  I  simultaneously  sprang  up  and  swiveled  my  head 
to  assess  the  situation,  it  took  me  a  moment  to  reg¬ 
ister  what  I  saw.  There,  swirling  around  my  son  like 
a  chaotic  yet  strangely  orchestrated  cloud  was  a  very 
angry,  substantial  swarm  of  hornets.  I  clenched  my 
jaw,  dropped  my  head,  and  went  in.  Needless  to  say, 
the  insects  carried  the  day,  easily  defeating  a  smarter, 
larger,  and  more  advanced  enemy;  the  swarm  had 
won. 

2  Background 

2.1  Problem  Description 

While  the  concept  of  swarming  is  well  known  in  na¬ 
ture  and  has  been  extensively  researched,  the  dawn 
of  the  information  age  has  only  recently  made  such 
tactics  possible  for  humans  (Arquilla  &  Ronfeldt, 
2000).  Specifically,  in  their  excellent  RAND  study  ti¬ 
tled  “Swarming  and  the  Future  of  Conflict,”  Arquilla 
and  Ronfeldt  remark: 

Swarming  has  two  fundamental  require¬ 
ments.  First,  to  be  able  to  strike  at  an 

1Does  not  include  man-portable  systems  (e.g.,  the  Raven). 


adversary  from  multiple  directions,  there 
must  be  large  numbers  of  small  units  of 
maneuver  that  are  tightly  internetted — i.e., 
that  can  communicate  and  coordinate  with 
each  other  at  will,  and  are  expected  to  do 
so.  The  second  requirement  is  that  the 
“swarm  force”  must  not  only  engage  in  strike 
operations,  but  also  form  part  of  a  “sen¬ 
sory  organization,”  providing  the  surveil¬ 
lance  and  synoptic-level  observations  nec¬ 
essary  to  the  creation  and  maintenance  of 
“topsight”  (Ibid,  pg.  22) 


With  this  in  mind,  bold  advances  in  communica¬ 
tion  capabilities  and  network  architectures  satisfy 
the  requirement  for  “tight  internetting.”  Likewise, 
new  data  fusion  software  quickly  transforms  myriad, 
seemingly  disparate  pieces  of  information  into  collec¬ 
tive  intelligence,  allowing  “topsight.”  In  short,  we 
have  the  means;  now  all  we  need  are  the  actors  -  the 
“the  many  and  the  small”  (Ibid.). 

While  various  manned,  tactical  combat  formations 
and  materiel  could  potentially  fill  this  void,  none 
show  the  promise  of  the  Unmanned  Aerial  System 
(UAS).  Capable  of  responsive  intelligence  gathering 
and  offensive  strikes  with  little  or  no  risk  of  friendly 
casualties,  UASs  have  firmly  solidified  their  place  in 
the  military  arsenals  of  many  countries.  For  example, 
in  2008  the  United  States’  Predator  UASs  alone  saw 
a  94%  increase  in  combat  flight  time  from  2007,  and 
over  1,000,000  UAS  combat  hours  have  been  flown 
since  the  start  of  the  Global  War  on  Terror  (See  Fig¬ 
ure  1)  (Shachtman,  2009). 1  In  order  to  meet  this 
surging  demand,  the  number  of  UASs  has  “increased 
from  167  unmanned  planes  to  5,331  in  the  past  five 
years,"  [and]  it’s  still  not  enough;  .  .  .  [djemaud  for 
video  is  more  than  four  times  the  supply”  (Shacht¬ 
man,  2008). 


1 


2  BACKGROUND 


Figure  1:  DoD  UAS  Flight  Hours  by  Department  by 
Fiscal  Year 


Coupled  with  the  proliferation  of  UAS  has  been  an 
ongoing  and  largely  successful  effort  to  miniaturize 
them.  For  instance,  consider  the  Battlefield  Air  Tar¬ 
geting  Micro  Air  Vehicle  (BATMAV)  depicted  be¬ 
low.2 


Clearly,  the  age  of  the  “many  and  the  small”  is  dawn¬ 
ing  for  UAS,  carrying  with  it  not  only  tactical  op¬ 
portunities  but  also  dilemmas,  not  the  least  of  which 
will  be  a  shortage  of  operators.  Specifically,  current 
UASs,  to  include  the  BATMAV,  require  at  least  one 
operator  per  system  and  larger  platforms  typically  re¬ 
quire  a  team.  If,  however,  the  supply  of  UAS  contin¬ 
ues  to  grow  in  the  face  of  increasing  demand,  multiple 
UAS  will  have  to  be  controlled  by  a  single  operator. 
With  the  emerging  n:l  UAS  to  operator  issue  on  the 
horizon,  it  is  not  surprising  that  the  second  goal  of 
Office  of  the  Secretary  of  Defense’s  (OSD)  FY2009- 
2034  Unmanned  Systems  Integrated  Roadmap  is  to 
“[sjupport  research  and  development  activities  to  in¬ 
crease  the  level  of  automation  in  unmanned  systems 
leading  to  appropriate  levels  of  autonomy,  as  deter¬ 
mined  by  the  Warfighter  for  each  specific  platform” 
(Department  of  Defense,  2009).  In  short,  algorithmic 
solutions  are  required. 


Figure  2:  BATMAV  UAS 


Designed  by  AeroVironment  for  the  United  States 
Air  Force’s  Special  Operations,  the  BATMAV  is  11.5” 
long,  has  a  16.5”  wing  span,  and  weighs  only  1  pound 
(Department  of  Defense,  2009,  pg.  68).  Yet  despite 
its  diminutive  size,  the  BATMAV  is  equipped  with  an 
“internal  Global  Positioning  System  /  Inertial  Navi¬ 
gation  System,  autopilot  and  two  on-board  cameras,” 
and  it  can  fly  at  roughly  40  mph  for  45  minutes  out 
to  a  range  of  5  km  (Ibid).  While  this  is  nothing 
short  of  astonishing,  “future  systems  could  fly  tran- 
sonically  for  1,000  kilometers  or  endure  for  tens  of 
hours”  (Abatti,  2005,  pg.  18-19). 


2.2  Objective  and  Principal  Tasks 

The  Aviation  and  Missile  Research,  Development, 
and  Engineering  Center  (AMRDEC)  Advanced  Sci¬ 
ence  and  Technology  Unmanned  Systems  Office  plans 
the  way  ahead  for  LIAS.  Their  intent  is  to  pursue 
technologies  that  increase  the  functionality  of  UAS 
while  simultaneously  reducing  the  workload  on  the 
user.  Recent  Operations  Research  Center  of  Excel¬ 
lence  (ORCEN)  research  by  MAJ  Ed  Teague,  DSE-R- 
0808,  showed  that  simple  rule  sets  can  organize  mul¬ 
tiple  UAS  to  complete  tasks  with  little  or  no  input 
from  controllers/users  (Teague  &  Kewley,  2008).  As  a 
matter  of  design,  DSE-R-0808  employed  biomimicry 
to  model  a  swarm  of  UAS  as  a  colony  of  ants,  where 
each  UAS  dynamically  updates  a  global  memory 
map,  allowing  pheromone-like  communication  (see 
DTIC:  ADA489366  for  additional  details).  In  par¬ 
ticular,  the  major  findings  of  DSE-R-0808  were: 

•  Semi- Autonomous  Self-Organizing  (SASC)  UAS 
are  possible  using  preprogrammed  tasks  and 
pheromone  communication  methods. 


2Figure  taken  from  the  Directory  of  U.S.  Military  Rockets  and  Missiles,  Appendix  f:  Undesignated  Vehicles,  Wasp  at 
http:/ /www. designation-systems. net /dusrm/app4/ wasp.html. 
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•  Depending  on  the  rate  of  pheromone  decay  and 
the  influence  of  distant  pheromone  levels,  multi¬ 
ple  UAS  seem  to  sufficiently  cover  a  large  area 
without  any  input  beyond  a  global  rule  set. 

•  SASC  behaviors  were  tested  via  federated  sim¬ 
ulation,  and  its  performance  is  comparable  to 
preprogrammed  routing  without  the  overhead. 

With  this  in  mind,  this  year’s  objective  was  to  ad¬ 
vance  the  efforts  of  DSE-R-0808  through  improved 
rule  sets  in  order  to  achieve  better  results  using  doc¬ 
trinal  mission  sets  employing  semi-autonomous,  self¬ 
organizing  UAS  in  dynamic  environments.  Accord¬ 
ingly,  the  principal  research  tasks  were  as  follows: 

•  Develop  improved  rule  sets  for  controlling 
swarming  behavior. 

•  Develop  a  modeling  and  simulation  test  bed  for 
swarming,  small  UASs  in  order  to  test  the  dif¬ 
ferential  aspects  of  system  components. 

•  Evaluate  various  UAS  parameters  to  see  how  ef¬ 
ficient  /effective  a  swarm  would  be  given  a  set  of 
hardware  (software)  and  recommend  hardware 
(software)  solutions. 

2.3  Literature  Review 

Controlling  a  swarm  of  UASs  via  digital  pheromones 
is  not  new,  and  it  is  currently  being  pursued  by 
multiple  agencies.  Most  notably,  in  their  2002  ar¬ 
ticle  “Digital  Pheromones  for  Autonomous  Coordi¬ 
nation  of  Swarming  UAVs,”  Parunak  et.  al.  de¬ 
scribe  their  novel  pheromone  algorithm  (ADAPTIV), 
which  employs  attractive  and  repulsive  pheromones 
on  a  hex  grid  with  roulette  selection  (Parunak  et  al., 
2002).  More  recently,  Dasgupta  details  an  agent- 
based  approach  in  “A  Multiagent  Swarming  System 
for  Distributed  Automatic  Target  Recognition  Us¬ 
ing  Unmanned  Aerial  Vehicles”  (Dasgupta,  2008). 
In  addition  to  pheromones,  Bae  explores  a  chaos- 
based  approach  in  “Target  Searching  Method  in  the 
Chaotic  U AY."  where  UAS  movement  is  simulated 
using  Arnold’s  Equation  (which  models  the  behavior 


of  noncompressive  perfect  fluids)  and  Chua’s  Equa¬ 
tion  (which  models  a  simple  electrical  circuit)  (Bae, 
2004). 

Beyond  searching  algorithms,  Sujit  et  al.  explore 
negotiation-based  task  allocation  to  multiple,  neigh¬ 
boring  UAVs  (Sujit  &  Ghose,  2006),  and  efficient 
computation  methods  are  discussed  in  Walter  et 
al.’s  “UAV  Swarm  Control:  Calculating  Digital 
Pheromone  Fields  with  the  GPU”  (Walter  et  al., 
2006).  This  latter  article  is  somewhat  remarkable 
in  that  it  demonstrates  that  pheromone  field  calcu¬ 
lations  can  be  performed  30  times  faster  on  a  com¬ 
puter’s  GPU  versus  CPU  (Ibid.). 

While  incredibly  valuable,  however,  the  research 
to  date  has  focused  on  detecting  targets  that  are 
present,  not  on  denying  enemy  action.  Moreover,  it 
has  not  incorporated  a  priori  information  about  the 
underlying  terrain  or  enemy  activity  to  inform  the 
swarm.  Finally,  although  Bertuccelli  and  How  pro¬ 
vide  an  excellent,  rigorous  analysis  of  Bayesian  up¬ 
dating  for  a  single  UAS  (Bertuccelli  &  How,  2005), 
probabilistic  updating  has  not  been  used  to  influence 
the  behavior  of  the  swarm. 

2.4  Principal  Assumptions 

•  UAS  are  equipped  with  Traffic  alert 
and  Collision  Avoidance  Systems  (TCAS). 

While  airspace  may  be  deconflicted  using  al¬ 
titude,  it  is  unreasonable  to  imagine  that  a 
large  number  of  UAS  (e.g.,  100)  operating  in 
close  proximity  to  one  another  would  never  cross 
paths.  Additionally,  as  altitude  increases  the 
ability  of  sensors  and  communications  hard¬ 
ware  to  interface  effectively  with  the  ground  de¬ 
creases. 

•  UAS  flight  characteristics  enable  any  ad¬ 
jacent  grid  to  be  visited  next.  As  seen  in 
Figure  4,  each  UAS  within  the  swarm  will  se¬ 
lect  its  next  location  from  one  its  eight  adjacent 
grids.  With  this  in  mind,  UAS  of  the  future 
must  be  capable  of  rapid  changes  in  direction, 
as  opposed  to  the  smooth,  wide  sweeping  turns 
common  in  today’s  fixed  wing  UAS. 
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3  CONTROLLERS 


•  UAS  and  ground  station  communication 
and  processing  capabilities  allow  UAS  to 
upload  /  download  information  to  the 
global  memory  map  in  real-time. 

•  UAS  are  operating  over  a  featureless,  un¬ 
informed  AO.  As  discussed  in  Section  4,  this 
assumption  is  important,  because  it  forces  the 
swarm  to  treat  each  grid  square  equivalently.  In 
other  words,  locations  on  the  ground  cannot  be 
distinguished  as  high  or  low  threat. 

3  Controllers 

As  seen  in  Figure  3,  we  establish  a  rectangular  area 
of  operations  (AO)  A  consisting  of  X  x  Y  square  d- 
meter2  grids,  where  X  and  Y  represent  the  number 
of  horizontal  and  vertical  grid  squares  respectively, 
and  the  ordered  pairs  (x,  y)  represent  their  addresses, 
where  x  £  [0, . . . ,  X]  and  y  e  [0, . . . ,  Y], 


map,  the  symmetric  random  walk  does  not  utilize 
pheromones  at  all.  As  seen  in  Figure  4,  at  any  time 
t,  a  UAS  located  at  (x,y)  randomly  selects  the  next 
grid  square  to  search  from  its  set  of  8  adjacent  neigh¬ 
bors  (or  local  neighborhood)  with  equal  probability. 
In  the  event  the  UAS  is  located  on  the  boundary 
of  the  AO,  it  simply  drops  any  out-of-bounds  grid 
squares  from  the  set  and  redistributes  the  probabil¬ 
ity  proportionally. 
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Figure  4:  The  Local  Neighborhood 
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Figure  3:  The  Area  of  Operations 


Controller  #1  -  Symmetric  Random 
Walk 

While  the  previous  work  of  MAJ  Ed  Teague  fo¬ 
cused  on  pheromones  and  utilized  a  global  memory 


Controller  7^2  -  Deterministic  Local 
Neighborhood  Search 

In  layman’s  terms,  deterministic  local  neighborhood 
search  directs  UASs  to  focus  their  search  on  the 
neighboring  grid  square(s)  with  the  greatest  inter¬ 
visitation  time.  Mathematically,  at  any  time  t, 
the  weight  of  a  given  grid  square  (x,  y )  is  given 
by  Wx,y(t)  =  Px,y{t),  where  px,y(t)  represents  the 
pheromone  level  in  (x,  y).  At  t  =  0,  px,y{t)  =  0  Vx,  y , 
and  each  UAS  within  the  AO  searches  its  current 
grid  square.  At  this  point,  exponential  decay  begins 
according  to  the  relation  px,y(t )  =  r)X}Ve~x(d~t:B’y'> 
where  A  is  a  positive,  homogeneous  decay  constant, 
tXtV  is  the  last  time  a  UAS  searched  (x,y),  and  7 x>y 
is  a  binary  parameter  which  equals  1  once  (x,  y)  has 
been  searched  for  the  first  time  and  0  otherwise.  In 
order  to  select  the  next  grid  square  to  search,  a  UAS 
located  in  (x,  y)  will  examine  the  weights  of  the  grid 
squares  comprising  its  local  neighborhood.  Follow¬ 
ing  examination,  the  UAS  will  search  the  neighbor¬ 
ing  grid  square  with  the  lowest  weight,  and  ties  are 
broken  arbitrarily. 
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Qk(t)  =  < 


Qi(t)  = 
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x  v- 

EEp. 
0 


Q^{t)  —  (x—x+l)(y—l 
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c-l  y 

E  E  Pi,: 

i=0 j=0 
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Controller  ^3  -  Deterministic  Local 
Neighborhood  Search  with  Quadrant 
Averaging 

In  essence,  quadrant  averaging  modifies  the  deter¬ 
ministic  local  neighborhood  search  algorithm  to  ac¬ 
count  for  recent,  global  visitations,  driving  UASs 
to  search  the  neighboring  grid  squares  which  (a) 
have  not  been  visited  recently  and  (b)  lie  in  quad¬ 
rants  which  have  relatively  large,  recent  average  in¬ 
tervisitation  times.  Mathematically,  at  any  time  t, 
wXiV(t)  =  pXlV{t)  x  Qk{t),  where  px  y(t)  is  defined  as 
above  and  Qk(t)  represents  the  average  pheromone 
concentration  in  quadrant  k  =  1 ...  4.  As  seen  in 
Figure  5  on  the  following  page,  the  quadrants  are  de¬ 
fined  with  respect  to  a  UAS’s  current  location  ( x,y ), 
yielding  the  above  equations  for  Qk{t).  As  with  Con¬ 
troller  ff2,  the  UAS  will  then  evaluate  the  weights  of 
the  grid  squares  in  its  local  neighborhood,  and  subse¬ 
quently  search  the  neighboring  grid  square  with  the 
lowest  weight. 


Controllers  #4,  5,  6,  and  7  -  Mixture 
Models 


Simply  put,  these  algorithms  randomly  direct  a  UAS 
to  use  one  of  the  first  three  controllers  according  to 
the  probability  mass  function  given  below: 


for  {(a;  —  1,?/-|- 1),  (x,y  +  1)} 
for  {(#  +  1,2/  +  1),  (x  +  1,  y)} 
for  {{x,y-  1),  (x  +  l,y—  1)} 
for  {(x-l,y),(x-  l,y  —  1)} 

!Pi,  c=l 
Pi,  c  2 
P3,  C  =  3 
0,  otherwise 

For  example,  at  any  time  t,  there  is  P2  probability 
that  a  given  UAS  will  use  Controller  #2  to  select 
its  next  grid  square.  In  this  way,  Controllers  #4  - 
if  7  utilize  Controllers  ff  1  -  if  3  in  proportion  to  the 
mixing  parameters  specified  in  Figure  6  below: 


Controller 

Number 

Pi 

Pi 

Pi 

4 

1  /  3 

1  /  3 

1  /  3 

5 

1  /  2 

1  /  2 

0 

6 

1  /  2 

0 

1  /  2 

7 

0 

1  /  2 

1  /  2 

Figure  6:  Mixing  Parameters 


Controllers  #8  and  9  -  Controllers  #2 
and  3  with  Roulette  Selection 

Functionally,  Controllers  #8  and  if  9  are  very  simi¬ 
lar  to  if 2  and  jf 3,  respectively.  In  fact,  the  calcu¬ 
lation  of  pheromone  levels,  exponential  decay,  and 
quadrant  averaging  are  identical.  However,  after  a 
UAS  calculates  the  weights  for  its  local  neighbor¬ 
hood,  it  no  longer  automatically  selects  the  adja¬ 
cent  grid  square  with  the  lowest  weight  -  it  merely 
prefers  them  through  the  application  of  roulette  se¬ 
lection.  Heuristically,  roulette  selection  generates  a 
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Figure  5:  The  Quadrants 
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probability  mass  function  for  a  UAS  according  to  the 
weights  of  its  local  neighborhood.  Akin  to  a  roulette 
wheel,  the  UAS  then  determines  where  a  uniformly 
distributed  random  variable  between  0  and  1  (e.g., 
the  ball)  falls  within  the  cumulative  distribution  func¬ 
tion  (e.g.,  the  wheel’s  bins;  see  Figure  7  below). 


Local  Neighbor 

of (x,y) 

wx,y 

Normalized 

wx,y 

x- 1 ,  y+l 

0.423 

0.098 

x,  y+1 

0.954 

0.222 

x+l,y+l 

0.769 

0.179 

x-1,  y 

0.019 

0.004 

x+l,y 

0.212 

0.049 

x-1, y-1 

0.408 

0.095 

x,  y-1 

0.938 

0.218 

x+l,  y-l 

0.577 

0.134 

Total 

4.301 

1.000 

Neighbor 


0.004 


Figure  7:  Roulette  Selection  Example 

In  this  way,  the  UAS  is  more  likely  to  select  adjacent 
grid  squares  with  lower  weights,  thereby  injecting  a 
stochastic  element  into  an  otherwise  deterministic  al¬ 
gorithm.  Interestingly  enough,  the  use  of  roulette  se¬ 
lection  in  the  control  of  swarming  UAS  is  not  new. 
In  particular,  in  their  paper  "Digital  Pheromones 
For  Autonomous  Coordination  Of  Swarming  UAS" 
Parunak  et  al.  describe  its  use  in  the  ADAPTIV  al¬ 
gorithm  (Parunak  et  al.,  2002). 

4  Initial  Metrics 

Developing  improved  rule  sets  implies  that  we  want 
or  need  to  (a)  fix  a  problem  with  our  current  rule 


set,  (2)  ramp-up  its  current  performance,  or  (3)  in¬ 
ject  additional  capabilities.  Regardless  of  the  rea¬ 
son,  each  requires  that  we  develop  a  set  of  metrics  to 
assess  and  compare  the  algorithms.  Of  course,  this 
begs  the  question,  how  does  an  effective  swarm  be¬ 
have?  In  order  to  address  this,  we  assume  that  the 
UAS  are  operating  on  a  featureless,  uninformed  AO. 
Put  another  way,  we  do  not  have  intelligence  (en¬ 
emy  or  geospatial)  about  the  AO.  This  distinction  is 
quite  important,  because  it  forces  us  to  treat  each 
grid  square  equivalently.  In  other  words,  we  have  no 
reason  to  suspect  that  any  given  grid  square  is  more 
or  less  likely  to  contain  a  target.  Under  this  assump¬ 
tion,  some  potential  measures  of  swarm  effectiveness 
are: 

•  The  coverage  must  be  complete  (As  t  — >  oo,  all 
cells  are  visited.) 

•  The  coverage  must  eliminate  sanctuaries 

—  Geospatially:  All  cells  are  recurrent. 

—  Temporally:  The  coverage  minimizes  the 
time  between  cell  visitation. 

•  The  coverage  should  be  uniform  (As  t  — »  oo,  the 
number  cell  visitations  per  cell  are  nearly  equiv¬ 
alent.) 

•  The  behavior  should  appear  random  (acyclic 
geospatially  and  temporally) 

Accordingly,  we  developed  the  following  metrics: 

1.  Standard  Deviation  of  Visitation  Counts 

(<7nx  ):  NXiV  is  defined  as  the  number  times 
( x,y )  is  visited  (observed)  by  a  UAS  during  a 
simulation  run.  On  a  featureless,  uninformed 
AO,  a  good  algorithm  should  evenly  distribute 
its  visitations  between  the  grid  squares.  Accord¬ 
ingly,  we  can  use  the  standard  deviation  of  Nx>y 
to  gauge  the  closeness  of  the  visitation  counts, 
where  smaller  cqvx  are  preferred. 

2.  Maximum  Initial  Visitation  Time 

(Max  tx ,j/(1)):  Ma xtX}V{1)  is  defined  as  the  latest 

time  a  UAS  visits  any  ( x ,  y)  during  a  simula¬ 
tion  run.  One  may  think  of  this  quantity  as  a 
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measure  of  the  diffusive  speed  for  the  swarm, 
where  good  performing  algorithms  visit  each 
grid  square  within  the  AO  as  soon  as  possible, 
allowing  for  the  quick  detection  of  static  targets 
that  exist  at  t  =  0. 

3.  Maximum  Maximum  Intervisitation  Time 

((Max(Max  A tXtV)):  Mathematically,  the 

times  between  UAS  visitations  for  (x,y)  or 
A tXiV  are  defined  by  the  sequence  {tx>y(2)  — 

A,y(i)  )  A,y(3)  ~  ^,2/(2)  >  •  •  •  )  ^,2/(n+l)  _  Al/(n)  }  f°r 

n  €  () . .  NXtV  —  1].  Clearly,  the  maximum  of 

this  sequence  represents  the  best  opportunity 
for  an  enemy  combatant  to  act  within  (x,y) 
without  being  observed.  Accordingly,  good  al¬ 
gorithms  should  minimize  this  quantity  across 
the  entire  AO. 

4.  Maximum  Average  Intervisitation  Time 

(MaxAtr  ,y):  A tx  y  is  defined  as  the  average  time 

between  UAS  visitations  for  ( x,y ).  Similar  to 
the  above,  by  minimizing  the  maximum  average 
intervisitation  time,  a  swarming  algorithm  can 
effectively  frustrate  the  enemy’s  uninhibited  use 
of  any  portion  of  the  AO. 

5  Preliminary  Experimentation 
and  Analysis 

Prior  to  the  development  of  the  8  new  controllers, 
preliminary  testing  and  evaluation  were  performed 


on  last  year’s  algorithm  (Controller  #3).  Specifically, 
using  a  swarm  of  10  UAS  ( S  =  10),  an  arbitrarily 
sized  AO  {X  =  71,  Y  —  36),  and  a  sufficiently  long 
run  time  (T  =  30,000),  we  calculated  the  relative 
and  absolute  performance  of  Controller  ^3  on  the 
four  previously  mentioned  metrics.  Additionally,  in 
order  to  provide  informative,  realistic  results,  it  was 
necessary  to  scale  the  dimensions  of  each  cell  in  light 
of  the  published  cruising  speed  and  future  sensor  ca¬ 
pabilities  of  the  Shadow  UAS. 

For  example,  according  to  FMI  3-04.155,  the 
Shadow’s  estimated,  unclassified  cruising  speed  is  70 
knots  (Department  of  the  Army,  2006).  Following 
simple  dimensional  analysis,  this  equates  to  35.98  me¬ 
ters  /  second.  Moreover,  in  Table  2-7  of  FMI  3-04.155 
it  states  that  the  Shadow’s  current  observable  target 
area  is  3.5m  x  3.5m  (Ibid.,  pg.  2-9).  If  we  assume  an 
order-of-magnitude  increase  in  the  width  of  the  ob¬ 
servable  target  area  by  FY2020,  then  we  can  conve¬ 
niently  set  the  length  and  width  of  each  grid  square  to 
35m.  Using  this  scaling,  we  can  now  equate  each  unit 
of  simulated  time  to  1  second,  providing  a  good  ap¬ 
proximation  for  the  amount  of  time  required  to  tran¬ 
sit  and  observe  a  given  cell  within  our  AO.  Finally, 
in  order  to  initiate  the  replications,  we  directed  the 
swarm  to  enter  the  AO  from  the  north  at  cell  (20, 1) 
in  an  echelon-left  formation. 
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5.1  Visitation  Counts 

Throughout  the  simulation,  the  by-cell  visitation  times  were  continuously  calculated,  updated,  and  stored 
in  an  output  array.  This  data  was  then  post-processed  using  simple  Excel  pivot  tables  and  conditional 
formatting  to  generate  the  visitation  counts  figures  seen  below.  As  we  examine  the  relative  performance 
of  Controller  #3,  we  notice  a  greater  concentration  of  red-shaded  cells  in  the  center  of  the  AO,  while  the 
boundaries  appear  to  contain  more  green.  Moreover,  when  the  data  is  examined  in  an  absolute  sense,  where 
cells  visited  more  than  100  times  are  shaded  green,  the  affinity  of  the  UAS  for  the  boundary  becomes  more 
apparent.  Finally,  it  is  worth  noting  that  minimum  and  maximum  NXtV  were  48  and  176  respectively,  and 
oivx,B  =  16. 


Relative  Performance 
(Green  is  highest;  Red  is  lowest) 


Absolute  Performance 

(Green  >  100  visits  >  Yellow  >  75  visits  >  Red) 


Figure  8:  Cell  Visitation  Counts  for  Controller 
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5.2  Initial  Visitation  Times 

As  seen  in  the  relative  performance  graph  below,  there  is  a  clear  bias  for  the  area  surrounding  the  swarm’s 
point  of  entry.  This  is  to  be  expected,  and  it  serves  as  a  form  of  verification  more  than  an  indicator  of 
performance.  However,  when  the  same  data  is  examined  in  absolute  terms,  where  the  maximum  initial 
visitation  time  is  735  seconds  and  all  cells  visited  in  less  than  5  minutes  are  shaded  green,  the  overall  initial 
diffusive  performance  seems  adequate. 


Relative  Performance 
(Green  is  earliest;  Red  is  latest) 


Absolute  Performance 

(Red  >10  minutes  >  Yellow  >  5  minutes  >  Green) 


Figure  9:  Maximum  Initial  Visitation  Times  for  Controller 
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5.3  Maximum  Inter  visitation  Times 

While  the  initial  visitation  times  seem  quite  acceptable,  the  maximum  intervisitation  times  are  worrisome. 
Specifically,  in  relative  terms,  it  appears  that  the  LIAS  have  an  affinity  for  the  boundary,  as  shown  by 
the  denser  concentration  of  green  cells  around  the  edges  of  the  AO.  Moreover,  when  we  set  the  minimum 
acceptable  performance  to  1  hour,  nearly  all  cells  in  the  center  of  the  AO  fail  (as  indicated  by  the  red 
shaded  cells).  In  fact,  the  worst  performing  cell  had  a  maximum  intervisitation  time  of  7032  seconds  (or  1 
hour  and  57  minutes)!  When  we  contrast  this  poor  performance  with  the  acceptable  performance  on  the 
initial  visitation  times  (where  the  swarm  visits  each  cell  in  roughly  10  minutes),  one  thing  is  clear  -  diffusive 
performance  is  not  constant. 


Relative  Performance 
(Green  is  shortest;  Red  is  longest) 


Absolute  Performance 

(Red  >  1  hour  >  Yellow  >  30  minutes  >  Green) 


Figure  10:  Maximum  Intervisitation  Times  for  Controller 
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5.4  Average  Intervisitation  Times 

Similar  to  the  maximum  intervisitation  times,  the  relative,  average  intervisitation  times  indicate  that  the 
UAS  have  an  affinity  for  the  boundary.  To  the  contrary,  however,  the  absolute  performance  also  appears 
acceptable,  as  the  entire  AO  is  shaded  green  and  yellow,  indicating  that  all  cells  are  visited  in  less  than  10 
minutes  on  average.  Therefore,  when  we  consider  (a)  that  the  maximum  intervisitation  times  are  unaccept¬ 
able  and  (b)  that  the  initial  and  average  diffusive  performance  seem  adequate,  it  appears  that  the  swarm’s 
entropy  decreases  as  a  function  of  time.  In  other  words,  the  longer  the  simulation  runs,  the  more  ordered 
the  behavior  of  the  swarm  becomes. 


Relative  Performance 
(Green  is  shortest;  Red  is  longest) 


Absolute  Performance 

(Red  >10  minutes  >  Yellow  >  5  minutes  >  Green) 


Figure  11:  Average  Intervisitation  Times  for  Controller 
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UAV  T  rajectories 
S  =  10,  Controller  #3 


Figure  12:  UAV  Trajectories  in  Space/Time  (t  =  1  .  .  .  1000) 


5.5  UAV  Trajectories  in  Space  and  Time 

In  order  to  test  the  decreasing  entropy  hypothesis,  we  plotted  the  trajectories  of  the  UAS  in  space  and  time. 
Seen  Figure  12  below,  the  horizontal  plane  represents  the  AO,  and  the  vertical  dimension  is  time.  Within 
this  volume  each  of  the  erratic,  multicolored  lines  represents  the  location  of  a  UAS.  In  this  way,  Figure  12 
provides  a  snapshot  of  the  swarm’s  historical  contrails  over  the  first  1000  units  of  simulated  time.  When 
viewed  from  the  side  (the  top  panel)  or  from  the  top  (the  bottom  panel)  the  swarm’s  behavior  appears 
Brownian,  and  it  fills  the  volume.  In  other  words,  there  is  no  apparent  order;  it  appears  to  be  operating  as 
intended. 

When  we  advance  the  simulation  clock  to  22700  and  plot  the  swarm’s  contrails  for  the  subsequent  1000 
time  units,  a  much  different  picture  emerges.  Seen  in  Figure  13,  the  volume  is  not  filled,  and  the  coverage 
appears  sparse.  In  fact,  the  swarm  appears  to  have  actually  lost  UAS,  as  many  of  the  colorful  lines  from 
Figure  12  appear  to  missing!  Upon  closer  inspection,  however,  we  are  actually  observing  the  output  of  a  very 
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interesting  development  within  the  swarm  -  flocking.  Evident  in  the  small,  left  inset  of  Figure  13,  the  black 
line  is  actually  a  tight  grouping  of  UAS  flying  together,  confirming  the  the  decreasing  entropy  hypothesis. 


UAV  T  rajectories 
S  =  10,  Controller  #3 


Figure  13:  UAV  Trajectories  in  Space/Time  (t  =  22700  .  .  .  23700) 


Absolute  Performance 

(Green  >100  visits  >  Yellow  >  75  visits  >  Red) 


Figure  14:  Cell  Visitation  Counts  for  Controller  #3  (Near  Simultaneous  Visits  Removed) 
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With  this  in  mind,  when  we  control  for  flocking  by 
removing  the  near  simultaneous  visits  from  the  visi¬ 
tation  counts,  the  absolute  performance  of  Controller 
#3  significantly  degrades.  Specifically,  when  con¬ 
trasted  with  Figure  8,  the  decrease  in  absolute  per¬ 
formance  shown  in  Figure  14,  is  rather  astonishing 
and  poor,  as  the  average  visitation  count  drops  from 
96  to  22. 


6  Volume  Suppressed 

As  seen  above,  metrics  1-4  allow  us  to  compare  the 
relative  performance  of  the  controllers  against  each 
other  and  a  desired  standard  using  a  given  test  case, 
and,  based  on  the  previous  section,  Controller  #3  is 
inefficient  and  ineffective.  While  plotting  trajectories 
in  3-space  and  examining  metrics  1-4  are  extremely 
enlightening,  it  is  also  time  consuming  and  computa¬ 
tionally  clumsy.  Accordingly,  we  desire  a  holistic  met¬ 
ric  and  an  automated  way  to  evaluate  various  UAS 
parameters  (and  controllers)  to  see  how  efficient  and 
effective  a  swarm  would  be  given  a  software  solution. 

From  an  operational  standpoint,  the  swarm  should 
limit  the  ability  of  the  enemy  to  maneuver  freely. 
With  this  in  mind,  we  introduce  the  enemy 's  windows 
of  opportunity ,  space/time  windows  for  the  enemy  to 
maneuver  unobserved.  In  a  visual  sense,  these  win¬ 
dows  are  represented  as  rectangular  prisms  within  the 
space/volume  absent  of  any  UAS  contrails  (see  Fig¬ 
ure  15).  That  is,  over  a  contiguous  portion  of  the  AO 
throughout  a  given  duration  of  time,  no  UAS  passed 
overhead.  In  this  way,  the  terrain  is  unobserved,  and 
the  enemy  may  act  with  impunity.  Accordingly,  good 
controllers  should  minimize  the  volume  of  these  rect¬ 
angular  prisms.  Put  another  way,  they  should  maxi¬ 
mize  the  space/time  volume  suppressed. 

Additionally,  there  is  a  minimum  amount  of  time  re¬ 
quired  for  an  enemy  to  take  action  within  a  given 
area.  For  example,  if  a  UAS  observed  a  given  grid  at 
11:30:05  AM  and  the  next  UAS  passed  overhead  at 
11:30:23  AM,  it  is  unrealistic  to  think  that  an  insur¬ 
gent  could  have  placed  an  improvised  explosive  de¬ 
vice  (IED)  during  the  18  seconds  of  unobserved  time. 


Moreover,  even  if  the  insurgent  could  place  the  IED 
in  18  seconds,  he  undoubtedly  would  delay  his  em¬ 
placement  both  before  and  after  the  passage  of  the 
first  UAS,  as  he  would  hear  and  /  or  see  the  UAS 
both  before  and  after  the  actual  observed  time,  but 
he  would  not  know  exactly  what  terrain  the  UAS  was 
observing.  In  sum,  while  there  was  18  seconds  of  un¬ 
observed  time,  the  area  was  successfully  suppressed. 

In  the  same  way,  we  need  to  consider  the  minimum 
amount  of  stand-off  distance  for  an  enemy  to  take 
action  at  a  given  location.  Using  the  example  above, 
if  a  UAS  observed  a  given  grid  at  11:30:00  AM  and 
the  next  UAS  passed  overhead  at  12:30:00  PM,  then 
we  might  think  that  any  reasonably  competent  in¬ 
surgent  could  have  place  an  IED  during  the  hour  of 
unobserved  time.  However,  if  a  UAS  passed  overhead 
in  at  least  one  adjacent  grid  every  30  seconds  during 
this  hour,  then  it  is  unrealistic  to  think  that  an  in¬ 
surgent  would  have  placed  an  IED.  Simply  put,  there 
is  just  too  much  UAS  activity  in  close  proximity  to 
his  location,  and,  once  again,  the  insurgent  does  not 
know  exactly  what  terrain  the  UASs  are  observing. 
The  area  was  successfully  suppressed. 

procedure  calculate  volume  suppressed 

for  x  =  1  to  X 
for  y  =  1  to  Y 
for  t  =  0  to  T 

if  there  is  no  UAV  in  ( x ,  y,  t) 
then  i  =  i  +  1 
else 

if  i  >  t! 

then  VUS  =  VU S  +  i 
i  =  0 

end  for  t  =  0  to  T 
end  for  y  =  1  to  Y 
end  for  x  =  1  to  X 

VS=  1  -  VUS/{X  xY  xT) 
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Figure  15:  Enemy  Windows  of  Opportunity 


With  this  in  mind,  we  define  width  of  opportunity 
( w  ')  and  time  of  opportunity  ( t ')  thresholds  that  es¬ 
tablish  these  minimums.  As  such,  in  order  for  a  grid 
to  be  successfully  suppressed,  a  UAS  need  only  pass 
overhead  within  w’  grids  and  within  V  time  units 
of  the  previous  suppression.  In  the  simplest  case 
(e.g.,  when  w '  =  0),  the  pseudo-code  for  calculating 
volume  suppressed  (VS)  from  volume  unsuppressed 
( VUS )  is  given  on  the  previous  page. 


7  Controller  Comparison 


Volume  Suppressed 

( f(Width  of  Suppressed  Area),  Swarm  Size  =  8,  dt  =  25 ) 


Width  of  Suppressed  Area 
(grid  squares) 


Armed  with  volume  suppressed,  we  are  now  ready  to 
compare  the  9  controllers.  Using  a  swarm  of  eight 
UAS  (5  =  8),  we  set  V  =  25  time  units  and  record 
their  the  performance  for  w’  =  1  to  36.  As  seen  in 
Figure  16,  Controllers  ff2  and  ff3  clearly  underper¬ 
formed  their  stochastic  competitors,  to  include  the 
simple  random  walk. 


Figure  16:  Controller  Performance  -  Volume  Sup¬ 
pressed  as  a  Function  of  Area  Width  (V  =  25) 

When  t’  is  increased  to  300  time  units  (5  minutes), 
we  begin  to  see  separation  among  the  stochastic  con¬ 
trollers,  especially  among  the  mixture  models  with 
Controller  #7  (a  mixture  model  which  randomly  se- 
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lec.ts  between  Controllers  ff2  and  #3)  emerging  as 
the  best  alternative  (see  Figure  17).  In  fact,  when 
V  is  increased  to  600  time  units  (representing  a  10 
minute  time  of  opportunity  threshold),  Controller  ff7 
is  able  to  suppress  over  85%  of  the  space/time  volume 
even  at  an  w:  of  1  (see  Figure  18),  while  last  year’s 
best  controller,  Controller  ff  3 ,  does  not  see  this  per¬ 
formance  until  w ’  reaches  24.  In  short,  Controller  ffl 
is  very  effective. 


Volume  Suppressed 

( /(Width  of  Suppressed  Area),  Swarm  Size  =  8,  dt  =  300 ) 


Width  of  Suppressed  Area 
(grid  squares) 


Figure  17:  Controller  Performance  -  Volume  Sup¬ 
pressed  as  a  Function  of  Area  Width  (t'  =  300) 


Volume  Suppressed 

(/(Width  of  Suppressed  Area),  Swarm  Size  =  8,  dt  =  600 ) 


Figure  18:  Controller  Performance  -  Volume  Sup¬ 
pressed  as  a  Function  of  Area  Width  {V  600) 


While  viewing  volume  suppressed  as  a  function  of  w  ’ 


is  useful,  it  is  also  valuable  to  see  it  as  a  function  of 
the  swarm  size.  That  is,  given  a  set  t’  and  w\  what 
is  the  volume  suppressed  that  can  be  achieved  for  a 
swarm  size  S ?  To  examine  this  question,  we  looked 
at  controller  performance  for  swarms  of  1  to  34  with 
V  and  w’  set  to  300  and  4  respectively.  The  results 
of  these  experiments  are  given  in  Figure  19  below. 


Volume  Suppressed 

(f(Swarm  Size),  width  of  suppressed  area  =  4  grid  squares,  dt  =  300  ) 


Figure  19:  Controller  Performance  -  Volume  Sup¬ 
pressed  as  a  Function  of  Swarm  Size 


As  seen  above,  Controller  ffl  outperforms  all  oth¬ 
ers  for  swarms  of  3  or  more  UAS,  and,  even  with  a 
swarm  of  34,  Controller  ff3  cannot  outperform  Con¬ 
troller  ff7  with  a  swarm  of  5.  Simply  put,  Controller 
ff7  is  very  efficient. 

In  light  of  the  above  analysis,  Controller  ff7  per¬ 
forms  the  best  in  the  aggregate.  That  is,  Con¬ 
troller  ff7  maximizes  volume  suppressed  over  the  en¬ 
tire  space/time  volume.  Aggregation  (or  by  propor¬ 
tionality  averages),  however,  can  be  deceiving.  With 
this  in  mind,  we  can  examine  volume  suppressed  at 
the  individual  grid-level  to  determine  where,  if  at  all, 
Controller  ff7  may  be  weak  and  another  controller 
may  be  strong. 

Accordingly,  we  set  t’ ,  w\  and  S  to  300,  4,  and  8 
respectively,  and  we  compared  Controller  #7  to  Con¬ 
trollers  ffl,  #2,  and  #3.  From  Figure  20  on  the  next 
page,  it  is  obvious  that  Controller  #7’s  grid-level  vol¬ 
ume  suppressed  (denoted  by  the  light  blue  markers) 
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Volume  Suppressed  (%) 


7  CONTROLLER  COMPARISON 


Volume  Suppressed 

f(x,y),  Suppressed  Area  =  4  x  4;  dt  >=  300;  Swarm  Size  =  8 


Figure  20:  Volume  Suppressed  as  a  Function  of  Location 
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uniformly  outperformed  the  others.  Additionally,  it 
is  interesting  to  note  that  while  Controller  #1  (the 
Symmetric  Random  Walk)  outperformed  Controllers 
#2  and  #3;  the  mixture  of  Controllers  #2  and  #3 
(Controller  #7)  was  far  superior. 

8  Future  Work 

As  discussed  in  Section  2.3,  while  controlling  a  swarm 
of  UASs  via  digital  pheromones  is  currently  being 
pursued  by  multiple  agencies,  the  research  to  date  has 
focused  on  detecting  targets  that  are  present  and  has 
not  focused  on  area  denial.  Moreover,  documented 
efforts  have  neither  (1)  incorporated  intelligence  es¬ 
timates  to  guide  the  swarm  nor  have  they  (2)  used 
probabilistic  updating  to  influence  its  behavior.  Ac¬ 
cordingly,  it  is  natural  for  our  future  efforts  to  take 
us  in  these  directions. 

In  the  first  case,  the  development  of  several  promising 
threat  assessment  methods  (namely  Riese’s  Threat 
Mapper  and  Huddleston  and  Browns’  Multi-Level 
Models)  make  incorporating  intelligence  estimates 
relatively  straight  forward  (Karalus  &  Riese,  2009; 
Huddleston  &  Brown,  2009).  For  example,  if  we  re¬ 
place  the  constant  decay  parameter  A  in  px,y(t)  = 
7 with  the  non-homogeneous,  decay  pa¬ 
rameter,  Ap  =  A (1  +  £(/ (threatx iV)),  where  (a)  £  = 
1  if  the  threat  surface  is  active  and  0  otherwise  and 
(b)  f(threatx^y)  £  [0,1];  monotonically  increasing, 
then  we  can  add  an  appropriate  threat  premium  to 
cells  based  on  their  underlying  threat.  In  theory,  this 
formulation  will  increase  the  rate  of  decay  on  higher 
threat  cells,  causing  the  UAS  to  visit  them  more  fre¬ 
quently.  This  particular  approach  is  attractive,  not 
only  due  to  its  simplicity  but  also  its  generality,  as 
the  threat  map  can  effectively  be  turned  off  via  £.3 

While  this  proactive  approach  uses  prior  information 
to  influence  swarm  behavior,  the  UASs’  actual  ob¬ 
servations  provide  additional,  valuable  information, 
and  we  should  update  our  threat  assessments  based 


on  what  they  observe.  With  this  in  mind,  we  can 
model  the  underlying  threat  probability  itself  as  a 
random  variable  with  a  Beta(a,/3)  distribution.4  As 
the  Beta  distribution  is  conjugate,  if  a  UAS  observes 
a  threat  in  given  cell,  then  the  cell’s  updated,  poste¬ 
rior  threat  probability  distribution  is  Beta(a  +  l,/3), 
else  it  is  Beta(a ,  /3  +  1).  Exploiting  this  relationship, 
we  can  further  modify  px,y(t)  —  7 x,ye~Xpj!'vi't~t:c'y'> 
as  Px,y{t )  =  'yXye~(WlXp°>’y+W2Xrx’V^t-tx-y^  where 

A r  =  A(.U(P (threat  in  (x,  y))))  and  rui  +  w2  =  1. 
Again,  in  theory,  this  will  decay  cells  with  higher 
threat  probabilities  at  a  faster  rate,  thereby  focus¬ 
ing  the  swarm’s  attention  on  them  (without  ignoring 
the  less  threatening  areas).  Moreover,  the  incorpora¬ 
tion  of  the  weighting  parameters  w\  and  W2  allows  us 
to  tune  the  model  to  be  more  proactive  or  reactive  as 
required. 


9  Conclusions 

As  mentioned  in  Section  2.2,  the  principal  research 
tasks  for  this  study  were  to: 

•  Develop  improved  rule  sets  for  controlling 
swarming  behavior, 

•  Develop  a  modeling  and  simulation  test  bed  for 
swarming,  small  UASs  in  order  to  test  the  dif¬ 
ferential  aspects  of  system  components,  and 

•  Evaluate  various  UAS  parameters  to  see  how  effi¬ 
cient  /  effective  a  swarm  would  be  given  a  set  of 
hardware  (software)  and  recommend  hardware 
(software)  solutions. 

Based  on  the  performance  of  Controller  #7,  the 
Haskell  simulation  given  in  the  Appendix,  and  the 
development  of  volume  suppressed  (a  novel  metric 
for  assessing  relative  controller  performance  as  well 
as  gauging  swarm  efficacy),  we  have  delivered. 


3This  approach  was  successfully  modeled  in  2010  as  part  of  a  USMA  Department  of  Systems  Engineering  cadet  capstone 
project. 

4Bertuccelli  and  How  use  this  method  for  a  single  UAS  in  “Robust  UAV  search  for  Environments  with  Imprecise  Probability 
Maps,”  IEEE,  2005,  pg.  5680-5685. 
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While  this  is  satisfying  from  an  analyst’s  perspective, 
it  provides  little,  tangible  value  if  it  does  not  bene¬ 
fit  the  ultimate  stakeholder,  the  Small  Unit  Leader. 
Fortunately,  the  recent  remarks  of  Dr.  Killion,  the 
Chief  Scientist  of  the  Army,  allay  this  concern: 

The  future  operating  environment  will 
see  a  significant  increase  in  the  use  of  un¬ 
manned  systems  requiring  the  direct  em¬ 
ployment  and  monitoring  of  multiple  sys¬ 
tems.  Unmanned  systems  must  be  able  to 
execute  complex  tactical  behaviors  in  com¬ 
plex  environments  with  minimal  required 
operator  control  or  intervention  thus  freeing 
the  Soldier  /  Robotic  Controller  to  be  able 
to  accomplish  other  mission  essential  tasks 
such  as  monitoring  the  unmanned  systems 


mission  package  and  the  tactical  situation. 
Future  Force  Soldiers  must  individually  pos¬ 
sess  an  expanded  ability  to  control  multi¬ 
ple  autonomous  /  semi-autonomous  systems 
(Killion,  2010). 

Accordingly,  in  20  years  time,  we  may  take  the 
“chaotic  yet  strangely  orchestrated”  movements  of 
large  numbers  of  UAS  for  granted,  as  swarms  du¬ 
tifully  collect  intelligence,  deter  enemy  action,  and 
perhaps  even  attack.  Surely,  its  algorithms  and  tech¬ 
nology  will  make  ours  look  novice  and  antique  by 
comparison.  Nonetheless,  should  we  see  such  a  day 
as  Dr.  Killion  suggests,  then  we  will  know  that  we 
played  an  early  albeit  small  role  in  a  development 
that  helped  Soldiers,  and  that  is  beyond  satisfying  - 
it  is  everything. 
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A  Haskell  Simulation  Code 

A.l  Main 


Main/Run 

Cook,  J.  MR  SSD,  Inc. 
2009 


1  Parameters  controlling  the  run 

1.1  Types  and  defaults 

data  RunParameters  m  aoi  =  RunParameters 
{runRandomSource  ::  SomeRandomSource 

,  runLength  ::  Double 

,  runUavFormation  ::  [(Trajectory ,  Loiter  Controller E)[ 

,  runHooks  ::  RunHooks  m 

} 

data  RunHooks  m  =  RunHooks 
{initializeRun  ::  [m  ()] 

,  initializeU av  ::  [  UAV  m  — >  m  ()] 

} 

defaultRunParameters  =  RunParameters 
{runRandomSource  =  defaultRandomSource 
,  runLength  =  30000 

,  runUavFormation  =  take  10 

[(trajectory ,  LC  (RandomWalk  (AOI  (100,100))  1)) 

|  trajectory  vFormation  50 

] 

,  runHooks  =  defaultRunHooks 

} 

defaultRunHooks  =  RunHooks 
{initializeRun  =  [] 

,  initializeU av  =  [] 

} 


1.2  Convenient  functions  for  adding  hooks 

addlnitHook  hook  params  =  params 
{runHooks  =  (runHooks  params) 
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{ initializeRun  =  hook  :  initializeRun  ( runHooks  params) 

} 

} 

addUavHook  hook  params  =  params 
{  runHooks  =  ( runHooks  params) 

{ initialize Uav  =  hook  :  initializeUav  ( runHooks  params) 

} 

} 

addUavEventHandlerHook  trigger  action 
=  addUavHook  $  A  uav  — >  do 
addUavEventHandler  uav  trigger  action 
return  () 


2  Invocation  of  a  run 


doRunWithMMapUpdates  cleanup  aoi  mmap  params  =  do 
doRun  $  addUavEventHandlerHook  trajectory  Changed 

( scheduleMemoryMapUpdates  cleanup  aoi  mmap)  params 
doRun  RunParameters 
{  runRandomSource  =  randomSource 
,  runLength  =  runLength 
,  runUavFormation  =  uavFormation 
,  runHooks  =  runHooks 
}  =  runEventGraph  $  do 
scheduleEventln  runLength  StopSim 
sequence _  ( initializeRun  runHooks) 
sequence _ 

[do 

uav  mkUav  n  startTrajectory 
scheduleEventAt  ( endT  startTrajectory)  (Arrive  uav) 
addUavEventHandler  uav  trajectory  Changed 
(doNext  o  Depart) 

addUavEventHandler  uav  completedTrajectory 
(runLoiter Controller  controller  randomSource) 
sequence _ 

[initUav  uav 

|  initUav  initializeUav  runHooks 

] 

|  n  [1 . .] 

|  (startTrajectory ,  controller)  uavFormation 
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3  The  simulation  machinery 

Control  flow  is  quite  simple,  and  once  you  grok  it’s  pretty  easy  to  manipulate. 
A  rough  overview  of  what’s  going  on: 

3.1  Arrive 

A  UAV  arrives  at  its  intended  destination.  It  triggers  the  “completed  trajectory” 
event  for  the  uav,  causing  the  loiter  controller  to  run  and  select  a  new  trajectory. 
The  assignment  of  a  new  trajectory  causes  the  Depart  event  to  be  scheduled 
as  well  as  (possibly  many)  UpdateMemoryMapCell  event(s)  and  callback(s)  to 
onEnterCell. 

data  Arrive  m  =  Arrive  ( UAV  m) 

instance  Monad  m  =>  MonadEvent  m  ( Arrive  m)  where 
describeEvent  ( Arrive  uav )  =  do 
uav  <—  describeUav  uav 
return  (text  "Arrive"  <+>  parens  uav ) 
runEvent  (Arrive  uav )  =  do 
fireUavEvent  uav  completedTrajectory  uav 
return  () 


3.2  Loiter  controller  invocation 

Each  UAV  will  have  this  hook  registered  to  evaluate  its  loiter  controller  whenever 
it  reaches  the  previously  assigned  destination. 

runLoiterController  randomSrc  controller  uav  =  do 
currentPos  getCurrentPosition  uav 
dest  <—  chooseNextCell  randomSrc  controller  currentPos 
uav  LplotTrajectoryTol  dest 


3.3  Depart 

A  UAV  is  leaving  a  cell.  When  this  event  fires,  a  new  Arrive  event  is  scheduled 
at  the  time  the  uav  is  expected  to  complete  its  current  trajectory. 

data  Depart  m  =  Depart.  (UAV  m) 

instance  (Monad  m,  ScheduleEvent  m  Double  (Arrive  m))  =►  MonadEvent  m  (Depart  m)  where 
describeEvent  (Depart  uav)  =  do 
uav  <—  describeUav  uav 
return  (text  "Depart"  <+>  parens  uav) 
runEvent  (Depart  uav)  =  do 

trajectory  <—  getUavTrajectory  uav 
now  getCurrentTime 
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if  startT  trajectory  96  now 

then  fail  "Depart  fired  at  weird  time" 
else  do 

let  arrivalTime  =  max  0  (endT  trajectory  —  now ) 
scheduleEventln  arrivalTime  ( Arrive  uav ) 
return  () 


3.4  UpdateMemoryMapCell 

A  uav  is  entering  a  cell.  Which  uav  is  irrelevant.  The  cell  will  be  “touched” 
and  nothing  else  happens. 

data  UpdateMemoryMapCell  mmap  cell 

=  UpdateMemoryMapCell  ( TVar  mmap)  cell  Double  Double 
instance  MonadEvent  EventM  ( UpdateMemoryMapCell  MMap_  Cell) 

where 

describeEvent  ( UpdateMemoryMapCell  _ mmap  cell  tO  tl)  = 
return  o  feat  o  map  text 
$  words  "Mark  memory  map  at  cell" 

-H-  [show  cell ] 

-H-  words  "at  times" 

-H-  [show  (tO,  tl)] 

runEvent  ( UpdateMemoryMapCell  mmap  cell  tO  tl)  = 

modifyReference  mmap  ( addObservationRange  cell  ( tO,tl )) 


3.5  Scheduling  updates  to  the  memory  map 

Whenever  a  uav’s  trajectory  changes,  scheduleMemoryMapUpdates  is  invoked 
to  schedule  UpdateMemoryMapCell  events  for  every  cell  that  the  specified  tra¬ 
jectory  will  touch,  as  well  as  (optionally,  controlled  by  the  cleanup  parameter)  a 
cleanup  hook  to  cancel  pending  updates  if  the  trajectory  changes  prematurely. 

scheduleMemoryMapUpdates  cleanup  aoi  mmap  uav  =  do 
trajectory  <—  getUavTrajectory  uav 

let  transitions  =  cellTransitionsOnTrajectory  aoi  trajectory 
spans  =  [(tO,  tl ,  cell) 

|  (tO,  cell)  <—  spanEnds 
|  (tl,J)  drop  1  spanEnds 

] 

spanEnds  = 

maybeToList  (timePos2Cell  aoi  (startT  trajectory)  (startPos  trajectory)) 
-H-  transitions  4f 

maybeToList  (timePosSCell  aoi  (endT  trajectory)  (endPos  trajectory)) 
—  schedule  events  and  return  (time,  eventld) 
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events  <—  sequence  $ 

[do 

—  at  time  span  begins,  tag  the  cell  for  the  duration  of  the  span 
eld,  scheduleEventAt  tO  ( UpdateMemoryMapCell  mmap  cell  tO  tl) 
return  ( tO ,  eld) 

|  (tO,  tl ,  cell)  <—  spans 

} 

—  add  hook  to  cancel  future  events  if  the  trajectory  changes 
when  cleanup  $  addOneShotUavEventHandler  uav  trajectory  Changed  $  A  _uav  — »  do 
now  getCurrentTime 
mapM_  cancelEvent 
[ event 

|  (t,  event)  events 
,  t  >  now 
] 

return  () 
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A. 2  Neighborhood 


SimpleUav/Neighborhood 

Cook,  J.  MR  SSD,  Inc. 

2009 


1  A  type  describing  neighborhoods  of  cells 

At  present,  only  two  types  of  neighborhood  are  implemented  -  the  empty  neigh¬ 
borhood  and  a  very  simple  neighborhood  defined  by  two  radii.  The  first  spec¬ 
ifies  one  half  the  side  length  of  a  square.  The  second  specifies  a  manhattan 
distance  inside  which  will  not  be  searched.  In  all  experiments  performed  for 
MAJ  Dabkowski’s  work,  the  values  used  were  1  and  0  respectively,  giving  a 
neighborhood  consisting  of  the  8  cells  adjacent  to  the  aircraft’s  current  cell. 

data  Neighborhood  a  where 

Empty  Neighborhood  ::  Neighborhood  a 
SimpleNeighborhood  ::  ( Num  a,  Enum  a,  Ord  a,  Show  a)  => 
a  — >  a  — >  Neighborhood  (a,  a ) 
empty  Neighborhood  ::  Neighborhood  a 
empty  Neighborhood  =  Empty  Neighborhood 

SimpleNeighborhood  ::  (Num  a,  Enum  a ,  Ord  a,  Show  a)  =>  a  — t  a  Neighborhood  (a,  a) 
SimpleNeighborhood  rl  r2 

|  null  ( cellNeighborhood  ( SimpleNeighborhood  rl  r2)  (0,0)) 

=  Empty  Neighborhood 
|  otherwise  =  SimpleNeighborhood  rl  r2 


2  Sampling  Neighborhoods 

The  cellNeighborhood  function  converts  the  specification  for  a  neighborhood  into 
a  function  which  actually  lists  the  cells  in  the  neighborhood  of  a  specified  cell. 
The  CellNeighborhood  type  is  a  convenient  alias  for  the  type  of  such  functions. 

type  CellNeighborhood  a  =  a  -*  [a] 
cellNeighborhood  ::  Neighborhood  a  — >  CellNeighborhood  a 
cellNeighborhood  Empty  Neighborhood  _  =  [] 
cellNeighborhood  ( SimpleNeighborhood  rl  r2)  ( x ,  y)  = 

[(a;  +  dx,  y  +  dy)  \  dx  <—  [—rl  .  .rl] 

,  dy  <—  [—rl  .  .rl] 
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,  abs  dx  +  abs  dy  >  r2 


3  Sampling  neighborhoods  based  on  position 

Similarly,  positionNeighborhood  looks  up  which  cells  are  in  the  neighborhood 
of  a  specified  spatial  location.  The  correspondence  additionally  depends  on 
an  IrregularCellularAOI  with  cells  of  the  appropriate  type.  Cells  that  are  not 
a  part  of  the  AOI  are  excluded  from  the  neighborhood,  and  if  none  are  left 
after  filtering  or  if  the  position  given  is  not  in  the  AOI,  then  a  neighborhood  is 
returned  consisting  of  one  or  more  arbitrary  cells  nearest  the  position. 

type  PositionNeighborhood  a  =  ( Double ,  Double)  — »  [a] 
positionNeighborhood  ::  IrregularCellularAOI  aoi  cell  => 

aoi  — >  Neighborhood  cell  — >  PositionNeighborhood  cell 
positionNeighborhood  aoi  cn  position  = 

case  cellContainingPosition  aoi  position  of 
Nothing  — >  cellsN ear Position  aoi  position 
Just  cell  — »  let  neighborhood  = 

filter  ( celllnAoi  aoi)  ( cellNeighborhood  cn  cell) 
in  if  null  neighborhood 

then  cellsNearPosition  aoi  position 
else  neighborhood 
simplePositionNeighborhood  :: 

( IrregularCellularAOI  aoi  (a,  a) 

,  Num  a,  Enum  a,  Ord  a,  Show  a 
)  =>  aoi  — >  a  — »  a  — >  PositionNeighborhood  (a,  a) 
simplePositionNeighborhood  aoi  rl  r2  = 

positionNeighborhood  aoi  ( simpleNeighborhood  rl  r2) 
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A. 3  Cell  Selection 


SimpleUav/CellularChooser 

Cook,  J.  MR  SSD,  Inc. 

2009 


1  Cell-score-based  controller  support  code 

Both  the  SimpleNeighborhood  and  QuadrantAveraging  controllers,  and  many 
others  that  might  be  implemented  later,  are  based  on  a  cell-scoring  or  -weighting 
model,  where  cells  are  nominated,  scored  or  weighted,  and  selected  based  on  the 
score  or  weight.  Two  models  are  implemented  here  for  performing  the  actual 
selection  for  such  a  scheme. 

The  runCellularChooser  uses  a  cellular  chooser  to  implement  the  selection 
part  of  a  controller’s  task.  It  produces  a  list  of  candidates  (which  by  con¬ 
struction  of  the  positionNeighborhood  function  will  not  be  empty)  and  chooses 
from  among  them  according  to  the  cellular  chooser.  Also  by  construction  of 
positionNeighborhood,  the  cell  chosen  will  be  inside  the  AOI,  so  the  final  con¬ 
version  back  to  a  cell  position  will  not  fail. 

class  CellularChooser  chooser  score  where 
chooseCellByScore  ::  chooser  —¥  [cell] 

— »  ( cell  — >  score ) 

— >  RVar  cell 

data  Chooser  score  where 

Chooser  ::  ( CellularChooser  chooser  score,  Show  chooser) 

=►  chooser  — >  Chooser  score 
instance  CellularChooser  ( Chooser  score)  score  where 
chooseCellByScore  ( Chooser  c)  =  chooseCellByScore  c 
instance  Show  ( Chooser  score)  where 
showsPrec  p  ( Chooser  c)  =  showsPrec  p  c 
runCellularChooser 

::  (IrregularCellularAOI  aoi  cell, 

CellularChooser  chooser  score) 

=►  chooser  —>  aoi  — >  (Double,  Double)  — >  Neighborhood  cell 
— >  ( cell  — >  score) 

— >  RVar  ( Double ,  Double) 

runCellularChooser  chooser  aoi  currentPos  neighborhood  score 
=  do  let  candidates 

=  positionNeighborhood  aoi  neighborhood  currentPos 
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when  ( null  candidates) 

(fail  "runCellularChooser :  no  candidates!") 

winner  <—  chooseCellByScore  chooser  candidates  score 
case  positionOfCell  aoi  winner  of 
Just  dest  — ¥  return  dest 

Nothing  — >  fail  ("runCellularChooser :  programming  error, 
44-  "selected  cell  was  not  in  the  AOI.") 

1.1  (Mostly-) Deterministic  selection 

The  Deterministic  chooser  first  selects  the  cell(s)  with  the  highest  score.  In 
case  of  a  tie,  a  uniformly-weighted  random  selection  is  made  from  the  list  of 
tied  cells. 

data  Deterministic  =  Deterministic 
deriving  ( Eq ,  Show) 

instance  ( Ord  score,  Distribution  Uniform  score) 

=4  CellularChooser  Deterministic  score 

where 

chooseCellByScore  Deterministic  candidates  score  =  do 
let  winners  =  maximaBy  ( comparing  score)  candidates 
randomElement  winners 

1.2  Roulette  selection 

The  Roulette  chooser  selects  from  a  list  of  cells  using  the  cells’  scores  as  relative 
weights  in  a  discrete  distribution. 

data  Roulette  =  Roulette 
deriving  (Eq,  Show) 
instance  (Ord  score,  Fractional  score, 

Distribution  Uniform  score) 

=4  CellularChooser  Roulette  score 
where 

chooseCellByScore  Roulette  candidates  score 
=  discrete  scoredCandidates 

where 

scoredCandidates  = 

[(score  c,  c) 

|  c  <—  candidates 
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A. 4  Controllers 


SimpleUav/LoiterCont rollers 

Cook,  J.  MR  SSD,  Inc. 

2009 


1  The  Loiter  Controller  class 

The  LoiterController  type  class  specifies  the  interface  loiter  controllers  must 
provide.  The  Loiter  Controller E  type  is  an  existential  type  allowing  loiter  con¬ 
trollers  of  different  types  to  be  handled  together. 

class  LoiterController  c  where 
describeLoiterController 
::  c  — y  10  Doc 
chooseNextCell 

::  ( MonadIO  m,  MonadTime  m  Double ,  RandomSource  m  s) 

=>  c  — »  s  — >  ( Double ,  Double)  —>  m  (Double,  Double) 
data  LoiterControllerE  =  V  c.  Loiter  Controller  c  =►  LC  c 
instance  LoiterController  LoiterControllerE  where 

describeLoiterController  (LC  c)  =  describeLoiterController  c 
chooseNextCell  (LC  c)  =  chooseNextCell  c 


2  Some  simple  controllers 

2.1  Random  Walk 

The  RandomWalk  controller  is  configured  with  a  distance  parameter  specifying 
the  maximum  number  of  cells  in  either  dimension  it  will  travel  each  time  it  makes 
a  decision.  The  distance  it  chooses  to  travel  in  each  dimension  is  independent 
of  the  other. 

If  the  chosen  destination  is  not  inside  the  AOI,  a  random  cell  inside  the  AOI 
is  chosen  from  among  those  nearest  the  current  position  of  the  UAV. 

data  RandomWalk  aoi  =  RandomWalk 
{  rwAoi  ::  aoi 
,  rwDist : :  Int 
} 

instance  (LrregularCellularAOI  aoi  (Int,  Int),  Pretty  aoi) 

=>  LoiterController  (RandomWalk  aoi)  where 
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describeLoiterController  ( RandomWalk  {. .})  = 
return  (text  "RandomWalk" 

<+>  pPrint  rwAoi 
<+>  pPrint  rwDist ) 

chooseNextCell  ( RandomWalk  {. .})  src  currentPos  =  do 
( dx ,  dy)  <—  sampleFrom  src  (randomJump  rwDist) 
let  destination  =  do  —  Maybe  monad 

(x,  y)  <—  cellContainingPosition  rwAoi  currentPos 
positionOfCell  rwAoi  ( x  +  dx,y  +  dy) 
case  destination  of 
Just  pos  —>  return  pos 

Nothing  — >  sampleFrom  src  ( jumpIntoAoi  rwAoi  currentPos ) 
randomJump  dist  =  jump 
where 

jump  =  do 

dx  uniform  (—dist)  dist 

dy  uniform  (—dist)  dist 

if  dx  =  0  A  dy  =  0 
then  jump 
else  return  ( dx ,  dy) 

jumpIntoAoi  aoi  currentPos  =  randomElement  candidates 
where  candidates  =  cellPositionsNearPosition  aoi  currentPos 


2.2  Local  Neighborhood 

The  SimpleNeighborhood  controller  implements  the  simple  exponential-decay 
pheremone-based  local  neighborhood  controller.  Operating  within  the  specified 
AOI,  according  to  the  specified  cellular  chooser,  it  selects  a  cell  from  within  the 
specified  neighborhood  based  on  scores  derived  from  the  memory  map. 

The  score  of  a  cell  is  given  as  one  minus  the  pheremone  level  for  that  cell. 
When  operating  under  the  deterministic  chooser,  the  cell  chosen  will  be  the  one 
with  the  maximum  score  (and  therefore  the  minimum  pheremone  level).  When 
using  the  roulette  chooser,  the  score  will  be  interpreted  as  a  relative  weight  for 
that  cell. 

data  SimpleNeighborhood  aoi  chooser  cell  mmap 
=  SimpleNeighborhood 
{  snAoi  ::  aoi 

,  snChooser  ::  chooser 

,  snLambda  ::  Double 

,  snNeighborhood  ::  Neighborhood  cell 

,  snMMap  ::  TVar  mmap 

} 

instance  (MemoryMap  mmap  cell 
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,  IrregularCellularAOI  aoi  cell 
,  Pretty  aoi 
,  Orel  cell,  Show  cell 
,  CellularChooser  chooser  Double 
,  Show  chooser 
)  =>  LoiterController 

( SimpleNeighborhood  aoi  chooser  cell  mmap) 

where 

describeLoiter Controller  ( SimpleNeighborhood  {. .}) 

=  return  ( text  "SimpleNeighborhood: " 

<+>  pPrint  snAoi 

<+>  text  ( show  snChooser) 

<+>  pPrint  snNeighborhood ) 
chooseNextCell  ( SimpleNeighborhood  {••})  sre  currentPos 
=  do 

mmap  readReference  snMMap 
t  <—  getCurrentTime 

let  score  cell  =  1  —  readDecayLevel  snLambda  mmap  cell  t 
let  destination  =  runCellularChooser  snChooser  snAoi 
currentPos  snNeighborhood  score 
sampleFrom  sre  destination 


3  Composite  controllers 

3.1  “Mixed”  controller 

Each  invocation  of  MixedController  randomly  chooses  from  the  provided  list  of 
controllers  with  the  associated  relative  probability  weights. 

newtype  MixedController 

=  MixedController  [(Double,  Loiter  Controller E)\ 
instance  LoiterController  MixedController  where 
describeLoiterController  (MixedController  cs)  =  do 
descriptions  sequence 
[do 

descr  describeLoiterController  c 

return  (hang  empty  8  (pPrint  p  o  colon)  <+>  descr) 

|  (p,  c)  <-  cs 

] 

return  (text  "MixedController: "  <+>  feat  descriptions) 
chooseNextCell  (MixedController  cs)  sre  currentPos  =  do 
c  <—  sampleFrom  sre  (discrete  cs) 
chooseNextCell  c  sre  currentPos 
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A. 5  Output  Analysis 


Main/Analysis 

Cook,  J.  MR  SSD,  Inc. 
2009 


Abstract 

This  module  defines  and  implements  the  basic  administrative  machin¬ 
ery  used  to  specify  which  analysis  data  to  generate  and  where  to  send 
it. 


1  Data  types  for  controlling  run  analysis  output 

The  AnalysisProduct  type  is  an  algebra  for  specifying  a  set  of  data  to  be  col¬ 
lected  during  or  after  a  run.  The  AnalysisParams  type  defines  all  user-tuneable 
parameters  controlling  the  data  collection  and  analysis  for  a  run,  including  a 
definition  of  where  (if  anywhere)  each  analysis  product  should  be  sent. 

The  anaOutput  field  of  AnalysisParams  specifies  zero  or  more  destinations 
for  each  AnalysisProduct  to  be  generated.  Its  type  is  parameterized  because  it 
will  initially  be  specified  as  a  String  specifying  the  file  path,  but  before  the  run 
those  files  will  be  opened  and  their  paths  replaced  by  file  handles. 


data  AnalysisProduct 
=  Metadata 
|  MMapUpdates 
|  MMapUpdatesByUav  Int 
j  MMapUpdatesByCell  Cell 
|  MMapCoverage 
|  VoidsBySquare  Square 
|  VoidsByCell  Cell 
|  VoidsBySize  Int 
|  VoidLengthsBySquare 
|  VoidLengthsBySize  Int 
|  MaxExtentBySquare 
|  ExtentStatsBySquare 
|  ExtentStatsBySize 
deriving  ( Eq ,  Ord ,  Read,  Show) 
data  AnalysisParams  h  =  AnalysisParams 
{anaRunName  :: String 

,  anaLoggerName  ::  String 
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,  anaOutput 
,  anaUnobsFilter 
,  anaAoi 
,  anaSeqMMap 
,  anaCleanup Events 
} 


Map. Map  AnalysisProduct  ]/t] 

Int  — >  Double  — >  Bool 

AO  I 

Bool 

Bool 


2  Predefined  sets  of  parameters 

Functions  to  construct  analysis  parameters  describing  standard  sets  of  analysis 
outputs.  These  are  parameterized  by  run  names,  because  they  specify  default 
filenames  for  the  outputs  as  well  as  which  outputs  to  produce. 


defaultAnalysisOutputs  runName  =  Map.fromList 
[(Metadata,  [runName  -H-  "  .txt"]) 

,  ( MMapCoverage ,  [runName  -H-  "  .txt"]) 

,  ( MMapUpdates ,  [runName  -H-  "_mmap.txt"]) 

] 

minimalAnalysisOutputs  runName  =  Map.fromList 
[(Metadata,  [runName  -H-  "  .txt"]) 

,  (MMapCoverage,  [runName  -H-  "  .txt"]) 


defaultAnalysisParameters  runName  =  AnalysisParams 
{  anaRunName  =  runName 
,  anaLoggerName  =  runName  -H-  "  .  analysis" 


,  anaOutput  =  defaultAnalysisOutputs  runName 

,  anaUnobsFilter  =  \_sz  _dt  — >  True 


,  anaAoi  =  AOI  (100, 100) 

,  anaSeqMMap  =  True 


,  anaCleanup  Events  =  False 

} 


3  Output  file  management 

Functions  to  handle  opening  and  closing  of  the  analysis  output  hies  used  in 
a  run.  openAnalysisFiles  is  slightly  more  complex  than  might  be  expected, 
because  it  caches  the  open  hie  handles  to  avoid  opening  the  same  hie  more  than 
once  if  it  is  the  destination  for  multiple  analysis  products. 

openAnalysisFiles  anaParams@ AnalysisParams 
{  anaOutput  =  outputNames}  =  do 

let  logger  =  anaLoggerName  anaParams 
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-H-  "  .  openAnalysisFiles" 

files  newRef  Map.  empty 

openedOutputs  Traversable. forM  outputNames  $  A  names  — > 

forM  names  $  A  name  — >  do 

cached  <—  reads  Ref  files  (Map. lookup  name) 
case  cached  of 
Just  handle  — >  do 

debugM  logger  $  unwords 
[  name 

, "already  opened,  returning  cached  handle" 

,  show  handle 

] 

return  handle 
Nothing  — »  do 

debugM  logger  $  unwords 
[  name 

, "not  yet  opened,  opening  and  caching" 

] 

handle  openFile  name  WriteMode 
hSetBuffering  handle  ( BlockBuffering  Nothing) 
modify  Reference  files  (Map. insert  name  handle) 
return  handle 

return  anaParams  {anaOutput  =  openedOutputs} 
closeAnalysisFiles  Analysis Params  {anaOutput  =  outputFiles} 

=  sequence _ 

[do 

isOpen  <—  hlsOpen  handle 
when  isOpen  $  do 
hFlush  handle 
hClose  handle 

|  handles  <—  Map.elems  outputFiles 
,  handle  <—  handles 


4  Analysis  output  routing 

The  following  functions  manage  the  routing  and  formatting  of  the  analysis  out¬ 
put  data.  lookupOutput,  lookupOutputs  and  lookup  Output  Where  retrieve  the 
file  handles  to  which  a  particular  piece  of  analysis  data  should  be  printed. 

The  various  output...  functions  compute  and  format  the  data  and  send  it 
to  the  appropriate  files.  The  multiOutput...  functions  do  the  same  for  data 
considered  to  be  a  part  of  multiple  analysis  products. 

Haskell’s  lazy  evaluation  is  used  in  a  critical  way  here  -  generally  speaking, 
these  functions  are  called  for  all  analysis  products,  regardless  of  whether  they 
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will  be  output  (or  of  how  many  times  they  will  be  output).  The  analysis  data  will 
be  passed  to  these  functions  in  unevaluated  form,  so  that  if  it  is  not  formatted 
and  printed,  it  will  not  be  unnecessarily  computed.  Similarly,  if  it  is  printed 
more  than  once,  it  will  not  be  unnecessarily  recomputed  or  reformatted. 

lookup  Output  prod  anaParams  = 

Map .findWit.hDefault  []  prod  ( anaOutput  anaParams) 
lookup  Outputs  prods  = 

lookupOutputs  Where  (e  prods ) 
lookupOutputs  Where  p  anaParams  =  nub 
[file 

|  (prod, files)  Map .toList  ( anaOutput  anaParams) 

,  p  prod 
,file  <—  files 
1 

{-#  INLINE  outputLn  #-} 
outputLn  anaParams  outType  line 
|  null  outputs  =  return  () 

|  otherwise  =  liftIO  $  sequence _ 

[hPutStrLn  out  line 
|  out  <—  outputs 

] 

where  outputs  =  lookup  Output  outType  anaParams 
outputRow  anaParams  outType  row 
|  null  outputs  =  return  () 

|  otherwise  =  liftIO  $  sequence _ 

[hPutStrLn  out  ( tabsep  row) 

|  out  <—  outputs 

] 

where  outputs  =  lookup  Output  outType  anaParams 
outputRow  Where  p  anaParams  row 
|  null  outputs  =  return  () 

|  otherwise  =  liftIO  $  sequence _ 

[hPutStrLn  out  o  tabsep  $  row 
|  out  <—  outputs 

] 

where  outputs  =  lookup  Outputs  Where  p  anaParams 
multiOutputRow  anaParams  outTypes  row 
|  null  outputs  =  return  () 

|  otherwise  =  liftIO  $  sequence _ 

[hPutStrLn  out  ( tabsep  row) 

|  out  <—  outputs 

] 

where  outputs  =  lookupOutputs  outTypes  anaParams 
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outputTable  anaParams  outType  table 
|  null  outputs  =  return  () 

|  otherwise  =  liftIO  $  do 
infoM  logger  $  unwords 

["Outputting  table  for" 

,  show  outType 

,  "to" 

,  show  ( length  outputs) 

,  case  outputs  of 
[_]  ->  "file. " 

-►"files." 

] 

dt  time _  $  sequence _ 

[hPutStrLn  out  ( tabsep  row) 

|  row  <—  table 
,  out  outputs 
} 

infoM  logger  $  unwords 

["CPU  time  used:" 

,  show  dt 
, "seconds" 

] 

where 

outputs  =  lookupOutput  outType  anaParams 
logger  =  anaLoggerName  anaParams  4f  " . "  4f  show  outType 
multiOutputTable  logger  anaParams  outTypes  table 
|  null  outputs  =  return  () 

|  otherwise  =  liftIO  $  do 
debugM  logger  $  unwords 
["Outputting  table  for" 

,  show  outTypes 
,  "to" 

,  show  ( length  outputs) 

,  case  outputs  of 
[_]  -►  "file. " 

->  "files." 

] 

dt  time _  $  sequence _ 

[hPutStrLn  out  ( tabsep  row) 

|  row  <r-  table 
,  out  outputs 
] 

debugM  logger  $  unwords 

["CPU  time  used:" 

,  show  dt 
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,  "seconds" 

] 

where 

outputs  =  lookup  Outputs  out  Types  anaParams 
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